Multiple computer systems often interact in order to achieve a goal, such as when an application program on a computer system interacts with other remote systems and applications in order to obtain various types of information and functionality that are not part of the application program. By performing such interactions, an application program may be able to leverage information and functionality from vast numbers of other computer systems over the Internet or other networks.
In order to enable such interactions between remote computer systems and application programs, various programmatic interaction mechanisms have been developed. For example, remote procedure call (“RPC”) protocols have long existed that allow a program on one computer to cause a program on another computer to be executed, and various object-oriented architectures such as CORBA (“Common Object Request Broker Architecture”) and DCOM (“Distributed Component Object Model”) provide similar capabilities. In addition, a variety of middleware programs have been implemented to connect separate applications (often of distinct types and from unrelated sources) to allow communication. For example, various EDI (“Electronic Data Interchange”) networks exist that provide standard mechanisms to allow a computer system of one user of the network to send data to a computer system of another user of the network.
The widespread popularity of the World Wide Web (“Web”) has provided additional opportunities for computers to inter-communicate. For example, much current Web use involves users interactively requesting Web pages from Web servers (e.g., via executing Web browser applications of the users) and receiving the requested information in response. In addition to such interactive user specification of requested information, there is also growing use of the Web to support the programmatic interaction of remote applications to exchange information via defined APIs (“application program interfaces”), such as APIs based on Web services interaction mechanisms. Such Web services allow heterogeneous applications and computers to interact, and can be defined and implemented using a variety of underlying protocols and techniques. For example, some Web service implementations return data in XML (“eXtensible Markup Language”) format using HTTP (“HyperText Transport Protocol”) in response to a Web service invocation request specified as a URI (“Uniform Resource Identifier”), such as a URL (“Uniform Resource Locator”) that includes a specified operation and one or more query parameters. In other implementations, additional underlying protocols are used for various purposes, such as SOAP (“Simple Object Access Protocol”) for standard message exchange, WSDL (“Web Services Description Language”) for description of service invocations, and UDDI (“Universal Description, Discovery, and Integration service”) for discovery of available services.
Unfortunately, while Web services and other programmatic interaction mechanisms allow various application programs and computers to interact, such interactions are typically limited in various ways. For example, the types of information and functionality that are available to be requested using such programmatic interactions are typically restricted to very limited types of requests that the remote computer systems and applications can automatically fulfill (e.g., to provide a specified predefined group of information, such as a Web page or file, or to perform a specified database query on a specified database), but there are often additional needed capabilities that are not available as part of the existing programmatic interaction mechanisms.
As one example of additional programmatic interaction capabilities that are often needed, one or more “source” (or “producer”) software programs may often need to provide multiple groups of data (e.g., messages) over time to one or more other “destination” (or “consumer”) software programs in a sufficiently reliable manner that the provided groups of data are rarely or never lost. However, such reliable data exchange creates various difficulties. As a threshold issue, the source and destination programs will typically need to be known to each other at design time so that they can be created in such a manner as to enable the data exchange interaction, such as by creating and including specialized functionality in the source and/or destination programs to enable the data exchange. Moreover, to actually perform the data exchange, the source and destination programs will both typically need to be simultaneously executing and accessible to each other, and the data exchange is susceptible to the loss of data in various situations, such as due to an occurrence of an error in or unexpected termination of one of the programs or based on a network error that interrupts communication between the programs. In addition, a common problem in such situations occurs when the source and destination programs have different abilities to process data, such as the source programs being able to send data more quickly than the destination programs can receive and process data—if so, complicated predefined techniques may be needed to regulate the flow of data, or instead groups of data being exchanged may be lost. Another common problem occurs in situations in which multiple programs wish to exchange data with multiple other programs, as such interactions are often difficult to organize and coordinate.
Thus, given the existing limitations regarding exchange of data between programs, it would be beneficial to provide a solution that enables software programs to reliably exchange data in such a way as to minimize or eliminate existing problems, as well as to provide a variety of additional capabilities.